Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000025_owner-urn-ietf _Wed Oct 9 12:11:59 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA19223 for urn-ietf-out; Wed, 9 Oct 1996 12:11:59 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA19217 for <[e-mail]>; Wed, 9 Oct 1996 12:11:21 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA26857  (mail destined for [e-mail]); Wed, 9 Oct 96 12:11:17 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA14137; Wed, 9 Oct 1996 10:10:59 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 09 Oct 1996 10:18:08 -0600
To: Larry Masinter <[e-mail]>, [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Larry Masinter (at least at 02:13 AM 10/9/96 PDT)

>Presumably if you have SRV records, you could use them for HTTP
>servers too, including http://www.purl.org.

Sorry, but SRV records cannot be used for HTTP without changing all
implementations of HTTP. The spec would also need to be changed to
say if SRV requests or A requests should occur first, because
behavior will differ.

>> Because it has "purl.org" in it which is OWNED by OCLC. They pay the
>> bill.
>
>Look, every place I've said "purl.org", change it to "purl.net" and
>register "purl.net" in a standards track document, 'owned' by IANA.
>
>If you did that, what would distinguishes 'urn.net' and 'purl.net' in
>terms of longevity?

Nothing. But there are distinctions other than longevity that
are important, starting with the overall design of the system.

You are not talking abut PURLs as set forth by OCLC. You are
talking about something that is halfway between the original Handle
proposal and PURLs. The idea of a global resolver (on replicated servers)
that would handle all resolution requests was the key feature of the
original Handle proposal. It was found unacceptable for several reasons,
two of which were:
 1) Potential for surgical denial of sevice attacks
 2) Organizations such as mine, who cannot put information about
    some of our documents into a system that is not cleared for
    handling classified work. (Company proprietary information is
    an analogous problem).

>> Because we don't to be tied to DNS. The URN framework (not NAPTR)
>> works in all situations no matter if you have DNS or not. You
>> can run the service in an OSI world using X.500 (everyone scream).
>
>I'm sorry, I was trying to establish the advantage of the NAPTR
>implementation against the PURL implementation of URNs, [...]

Every time I have heard the OCLC people talk about PURLs, they have
been careful to say that they are not URNs. Their focus was to do as
much as possible without changing client-side code.

>> 3) Other available protocols. The PURL doesn't tell me what other
>>    protocols are available and which one it considers the best.
>
>If the 303 response from HTTP includes multiple Location: results, you
>could pick the one you liked the best.

And 10 years from now, when HTTP has been supplanted by 2 generations
of further work in protocols, we are still supposed to start off
all resolution requests by sending an HTTP GET to something.purl.net?
I'm sorry, but this doesn't sound like a solution that will gracefully
adapt to the future.

>> There is not ONE killer reason why the URN framework is better than
>> PURLs. There are alot of smaller ones....
>
>I think you misunderstood: I'm not questioning the 'URN
>framework'. I'm questioning the NAPTR implementation of the framework.

Oh, that has not been clear to me. I thought you were looking for
a comparison between NAPTRs and PURLs. Since OCLC's PURLs are not an
implementation of the URN framework, and NAPTRs are supposed to be,
explaining some of the differences between them requires that we make
reference to the URN framework.

>I'm dubious about these DNS records with 'dblookup+N2C' in the middle
>of them and the idea that just because the syntax is embedded in DNS
>as a transmission mechanism that it isn't a 'protocol'.

I could be wrong about this, but I don't recall anyone ever saying that
NAPTRs were not a 'protocol', but please correct me if I am wrong about that.

You say you are "dubious" about the proposal. That's fine, lets
talk about your areas of concern.

Yesterday you raised a couple of concrete objections to the NAPTR "protocol",
namely that there was no versioning and that there was no change control
over the resolution protocols (rcds, rcds2, ..). I pointed out how we
could accomodate versioning in the flags field.
I also said that we should discuss change control on the protocols, and
that your suggestion that they be registered as URL schemes was a
reasonable starting point for the discussion. To begin that discussion
I also said that I was unsure this was the best thing to do, since in the
past some protocols (Z39.50 in particular) have had trouble mapping all
their capabilities into a URL. However, I don't have any better
suggestions at this time. Perhaps we should look to a registry like the
media type registry as our model?

These topics are very young, so nobody has had anything to say on them
yet. How about you? Does my suggestion of using the flags field overcome
your concern about versioning? If not, why not? Do you have any further
arguments on why a version field should be needed when we cannot change
the number, type, or order of fields in a DNS record once it is out there?
When clients and servers are not required to understand and support all
the N2C, N2L, ... requests?

Your point on versioning of the resolution protocols is well-taken. I
agree we should address that somehow - probably in the framework
document, but the NAPTR draft should, at least, cite the framework draft
as the source of information on that topic. We should discuss ow to do it,
so lets discuss it.
I assume you have more knowledge of the Z39.50 URL schemes than I,
is my concern about using URL standards-track documents as the "registry"
misplaced? What about an IMT-style registry instead?

Do you have any further concrete areas of concern about the NAPTR
implementation of the framework?


Later,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"